home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group97a.txt / 000074_icon-group-sender _Thu Mar 6 09:54:22 1997.msg < prev    next >
Internet Message Format  |  2000-09-20  |  3KB
  1. Received: by cheltenham.cs.arizona.edu; Thu, 6 Mar 1997 13:36:24 MST
  2. Date: Thu, 6 Mar 1997 09:54:22 -0800 (PST)
  3. From: Brian Rogoff <bpr@best.com>
  4. To: Ken Walker <kwalker@orville.premenos.com>
  5. Cc: bpr@best.com, icon-group@cs.arizona.edu
  6. Subject: Modules in Icon (Was Re: Recursive directory traversal in Icon)
  7. In-Reply-To: <199703061655.IAA10379@varda.premenos.com>
  8. Message-Id: <Pine.SGI.3.95.970306093623.4247A-100000@shellx.best.com>
  9. Mime-Version: 1.0
  10. Content-Type: TEXT/PLAIN; charset=US-ASCII
  11. Errors-To: icon-group-errors@cs.arizona.edu
  12. Status: RO
  13. Content-Length: 2693
  14.  
  15. On Thu, 6 Mar 1997, Ken Walker wrote:
  16. > > From: Brian Rogoff <bpr@best.com>
  17. > > Subject: Recursive directory traversal in Icon
  18. > > 
  19. > > (2) Why no module system? I've found modules helpful in every language I've 
  20. > >     worked with, and Icon doesn't seem to be different in that it could use
  21. > >     such a system. I noticed someone else mention this, but it is not in
  22. > >     the FAQ. Perl has benefitted greatly from the inclusion of modules.
  23. > 
  24. > 6 or 7 years ago, I implemented modules in ISI's attempt at a commercial
  25. > version of Icon (technicall, the U of A's version with proprietary extensions).
  26. > We produced a product, but the venture didn't get anywhere. The module
  27. > feature allowed better information hiding and helped manage the global
  28. > name space. A more "modern" approach to dealing with these (and other)
  29. > problems is "objects". Even before ISI's version of Icon, Clint Jeffery
  30. > created IDOL, an object-oriented version of Icon, implemented with a
  31. > preprocessor. The preprocessor is distributed as a part of the "Icon
  32. > Program Library".
  33.  
  34.     Given the choice between an object system, and a package/module 
  35. system, I'll take the package system. I see from your post that you are 
  36. a follower of Bertrandd Meyer ;-).
  37.  
  38. > It is possible to have both objects and modules in a language. Java packages
  39. > are modules. Within them you can declare classes. Because classes cannot
  40. > be nested and give the user of the class no control over visability,
  41. > classes don't give implementer as much cabability for information hiding
  42. > and doesn't give users as much control over their the global name space
  43. > as you'd like. Note that while objects are useful for projects of all
  44. > sizes, modules really become helpful only for larger projects.
  45.  
  46.     (1) Lots of languages have both objects and modules. Ada 95, Perl 5,
  47.             Common Lisp, C++ (namespaces), ...
  48.  
  49.     (2) Classes *can* be nested. Simula, BETA, Java 1.1, etc. Most OO
  50.         languages don't support this, but that just shows that there is 
  51.         no consensus. 
  52.  
  53.     (3) I don't find objects all that useful for small projects. I've 
  54.             even used languages without objects that had modules (SML) 
  55.             which were quite pleasant.
  56.  
  57. All that said, an object system would be nice too, and maybe Idol is good 
  58. enough for now.
  59.  
  60. > Maybe someday there will be a verion of Icon with both features, but someone
  61. > will have to be interested enough and have the resources to implement it.
  62.  
  63.     It would be nice if this were standard Icon. You saw a need for it, 
  64. I see a need for it, some other guy on the net who is a user found its 
  65. omission distressing. Anyone from the Icon group at U of A ever address
  66. this issue?
  67.  
  68. -- Brian
  69.  
  70.  
  71.